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THE INVENTION 

The appellants claim a method, semiconductor chip and 

computer graphics system for texture mapping. * Claim 1, directed 

toward the apparatus, is illustrative: 

1- Apparatus for texture mapping in a computer graphics 
system, using a predetermined set of standardized textures, the 
apparatus having an input to receive via a network identifying 
data identifying one of the set of standardized textures, and 
means for processing the data to generate output texels of the 
identified texture, wherein each texture of the standardized set 
is a procedural texture, the identifying data comprises one or a 
sequence of program commands, the execution of which will result 
in the generation of a respective procedural texture, with the 
means for processing data comprising a processor operable to 
implement all such input program commands or sequences of input 
program commands as required to generate the procedural textures 
of the standardized set. 
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THE REJECTIONS 

The claims stand rejected under 35 U.S.C § 103 as follows: 
claims 1-4, 7, 9 and 10 over Kamen in view of Jenkins, claims 5, 
6 and 8 over Kamen in view of Jenkins and Griffin, and claim 11 
over Kamen in view of Jenkins and Tremblay. 
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The opinion in support of the decision being entered today was 
not written for publication arid is not binding precedent of the 
Board- 
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Before BARRETT, OWENS and BLAN$ENSHIP, Administrative Patent 
Judges. 1 

OWENS, Administrative Patent Jtidge. 



DECISION ON APPEAL 

i 
I 

This appeal is frora the final rejection of claims 1-11, 

i 

which are all of the claims in the application. 



1 
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OPINION 

We reverse the aforementioned rejections. We need to 
address only claim 1, which claims an apparatus required by all 
of the other claims. 1 

Kamen discloses that some computer graphics systems use 
procedural texturing wherein texture values are calculated or 
derived from a mathematical function which is used to model the 
associated texture values (col. 2 f lines 29*-36) . These texture 
values are passed directly to a combinor module which combines 
these texture values with any existing pixel values (col. 2, 
lines 27-29 and 37-39; coK 6, lines 31-32). 

Jenkins discloses (col, 85, lines 49-58): 

Transmitted texture information includes conventional 
maps as well as parameters for procedural methods of 
texture synthesis which are then generated by the 
client. Alternatively, transmitted primitives can 
refer to materials* and textures from prestored 
libraries of textures maintained by the client. The 
use of procedural textures and prestored texture 
libraries reduces the required client-server connection 
bandwidth. The use of prestored texture libraries 
allows the user to modify the appearance of the model 
by selecting texture preferences. 



1 The examiner does not rely upon Griffin or Tremblay for 
any disclosure that remedies the deficiency in Kamen and Jenkins 
as to claim 1. 

3 
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The appellants' claim 1 requires an apparatus having an 
input to receive, via a network, identifying data that identifies 
one of a set of standardized textures and comprises one or a 
sequence of program commands whose execution will result in the 
generation of a procedural texture. 

The examiner argues that because a procedural texture can be 
a mathematical function, Jenkins' parameters transmitted to run 
the procedural texture have to include commands to place the 
parameters in the mathematical function (answer, page 9) . A 
parameter in programming is w a value passed to a subroutine or 
function for processing", 2 and w is synonymous with argument, a 
value that is passed to a routine." 3 As indicated by these 
definitions, parameters may be mere data, and the examiner has 
provided no evidence or reasoning which shows that parameters 
used in procedural textures must include commands to place the 
data in a mathematical function* Furthermore, the examiner has 
not explained how the applied references themselves would have 



2 TechEncyclopedia, 

http://www.techweb,com/encyclopedia/defineterm?term=parameter&x=4 
2&y-7, A copy of each dictionary definition cited herein is 
provided to the appellants with this decision. 

1 Webopedia, 

bttp : //www . pcweb opaedia . com/ TERM /p/p * t^m^t^y t fr^i i 

4 
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fairly suggested,, to one of ordinary skill in the art, using, as 
Jenkins' transmitted parameters, parameters which include such 
commands. 

The examiner argues that parameters can start and stop the 
running of a mathematical function and specify the number of 
iterations and that, therefore, Jenkins' parameters are program 
commands (answer, page 9) ♦ The examiner, however, has not 
established that Jenkins' parameters actually serve the purposes 
asserted by the examiner. Also, the examiner has not explained 
how the applied references themselves would have fairly 
suggested, one of ordinary skill in the art, the use of 
parameters that serve those purposes* 

For the above reasons we conclude that the examiner has not 
carried the burden of establishing a priina facie case of 
obviousness of the appellants' claimed invention. 



5 
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DECISION 

The rejections under 35 U.S.C. § 103 of claims 1-4, 7, 9 
and 10 over Kamen in view of Jenkins, claims 5, 6 and 8 over 
Kamen in view of Jenkins and Griffin, and claim 11 over Kamen in 
view of Jenkins and Tremblay, are reversed. 

REVERSED 



LEE E. BARRETT 
Administrative Patent Judge 



<2- 



TERrS^. OWENS 
Administrative Patent Judge 




HOWARD B. BLANKENSHIP 
Administrative Patent Judge 



BOARD OF PATENT 
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INTERFERENCES 



TJO/ki 
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Abstract 

Wc describe a software system on the Pixel-Planes 5 graphics 
engine that displays user-defined antialiased procedural 
textures at rates of about 30 frames per second for use in real- 
time graphic* applications. Our system allows » user to create 
textures thai can modulate both diffuse and specular color, the 
sharpness of specular highlights, the amount of transparency 
and the surface normals of an object. We describe a texture 
editor that allows a user to interactively create and edit 
procedural textures. Antialiasing is essential for real-time 
textures, and in this paper we present some techniques for 
antialiasing procedural textures. Another direction we are 
exploring is the use of dynamic textures, which are functions 
of tune or orientation. Examples of textures we have 
generated include a translucent fire texture that waves and 
niclcers and an animated water texture that shows the use of 
mapping)" 3 ™ 716 " 1 mapvmg and aorm ^ i perturbation (bump 

Introduction 

The current trend in graphics libraries is to give users 
complete control of an object's surface properties by 
providing! a language specifically for shading fflanrahan & 
^ w s°° *>J- There are two lines of research thaYhaveconw 
together to fonn modem shading languages. One line of 
research » the notion of programmable shatters, which has its 
mots in toe flexibility of the shatter dispatcher fWhitted I 
Weimer sz] and I which was expanded to folly programmable 
*f t t"' n . [C f^ M] : 1,16 othCT search trade is thTuseof 
mathematical function composition to create textures 
©chachterSO] [Gardner*!]. These two ImcsoKarch we!e 
dnmaticaUy brought together to produce a matareSng 
language m to* work of Ken Perlin (Pertin 85]. There are nol 
f^7i£ 8 ? hlCS l ? a - chinc5 fast CT »"gh to bring some of this 
rl^^i 0 J 6 2t tun o i« Til P hics Application! [Apgar 88] 
Hoffe « 89] [Fuchs 89]. This k me'pjim of 
departure for our research. 

^»^^^ 0f ^^ risMfolI< ^ adiscus «onofthe 
Planes 5 hardware and software; a brief description of our 

Ornntad provttlod that the copies ar9 not mad<> 0 , diau;buXKtS . 

B f ,VBm<,9a - *° ACM «=°PVrSaht notice and the 
t.t|« »f the puUioawn and its d« B Woa r, and notice is oivew 
£*t copy,n fl |, by pn**** of «ho ^^1^" 

and/or specific permission. 

♦ 1992 ACM 0.89791.471-6/92*)003/0O95._$l. 5 0 



language for composing textures; an outline of (he algorithms 
involved in displaying such textures on Pixel-Planes 5- a 
description of an interactive texture editor mat dynamically 
duplaysatexhireas the userchangesitsparanieteis; examples 
of dynamic textures; examples of applications that make use 
of trie, texture capabilities of our system; and future directions 
tor this research. 

Why Use Procedural Textures? 

Procedural textures provide an alternative to the choice of 
lmage-based textures. The central tradeoff between image 
and procedural textures is between memory cost and 
execution tune. 

Graphics architectures that are well-suited for displaying 
image textures typically have large amounts of memory 
associated with a handful of fast processors. Each mocessSr 
retains a copy of every image texture fbragiven scene so that 
any processor can perform the texture look-up at any given 
pixel in the scene. Texture evaluation thus has a small, fixed 
computational cost, at the expense of using large amounts of 
memory to store the texture copies. The Silicon Graphics 
Sky wnter and the Star Graphicon 2000 are two rornmTrcial 
graphics engines that use this approach with impressive 

Our implementation of procedural textures onPkel-Planes 5 
provides a look at the opposite end of this spectrum. Each 
pixel processor has only 20? bits of memory, but the graphics 
machine may be configured to have on the order of 256000 
pixel processors, giving the ability to perform several billion 
instructions per second. Their very small memory makes the 
pixel processors poor for rendering image-based textures but 
their computational power makes them ideal for generating 
procedural textures on-the-fly. fi 

^^* at ""y Pro^dural texture can be computed once, 

STfH f T* 6, andu * edina «*ne like any Sfher image 

r«£™ J? ![ canbc that image-based 

tex&r«offereye^ n g^ 

wuh (he only additional cost being the use of more memory 
Abo. ias clear that procedural textures arc a pocrchoicc when 
me scene requires a picture hanging on the wall or an imaee 
ontJ«covcrofabook. Nevertheless, procedural texnires IS 
,^5 flh ^ J 0wn - Orc benefit is that the tcxlwTcan 
be arbitrarily detailed, provided that the texturTcSiS 
are represented with enough bits. Each additional bit added to 
computation of a function of two variables is reflected by a 
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factor of four in memory cost to mimic the texture with a 
Stored image. A more dramatic benefit is the ability lo define 
textures which are functions of many variables, such as 
animated textures and solid textures. The memory capacity of 
graphics systems that we are familiar with is not large enough 
to explicidy store such textures, Pixel-Planes 5 offers us the 
alternative of evaluating on demand the values from textures 
of several variables. 

PixeNPIanes 5 Overview 

Hardware - Hie Pixel-Planes 5 machine has multiple Intel 
i860-based Graphics Processors (GPs) and multiple S1MD 
pixel processor arrays called Renderers. A Renderer is a 
128x128 array of bit-serial pixel processors, each with 208 
bits of localrnemory, called pbcelmemory, and 128x32 bits of 
off-chip backing store memory. Each Renderer can be 
mapped to any 128x128 pixel region of an image. The 
Renderer processors are capable of general arithmetic and 
logical operations and operate in S1MD mode. Each 
processor has an enable bit that regulates its participation in 
instructions, Graphics Processors, Renderer^ Frame BufifeTS, 
and workstation host conuntiracate over a shared 640 Mb/sec 
ring network- 
Software - Generating images with textured polygons On 
Pixel-Planes 5 is a multi-stage process which can be viewed 
as a graphics pipeline [Fuchs 89] as shown in Figure 1, 
Transparent polygons are handled fay making multiple passes 
through the pipeline. In thefirst stage of the graphics pipeline, 
the Graphics Processors transform the polygon vertices from 
model space to perspective screen space and create SlMD 
instruction streams (Image Generation Controller or IGC 
commands) for the Renderers to rasterize the polygons. A Z- 
buifer algorithm is executed in parallel for all pixels within a 
polygon. During rasterization, intrinsic color components, 
surface normals, texture u,v coordinates, texture scale factor 
(used for antialiasing), texture-id, etc. , are stored, in the pixels. 
After rasterization of an polygons, each pixel processor has 
the parameters of its front-most polygon. These parameters 
are (hen used in the next two stages of the pipeline: texture 
program interpretation and lighting model computation. At 
*F. *Jf ^9 n,n S °f texture program interpretation, some 
initialization is performed. The rasterization phase actually 



Graphics Processor 



| Polygon Data J j 



IGC Commands 




Figure 1; Pixel-Planes 5 Graphics Pipeline 



stores u«z and vi rather than u and v in pixel memory (since 
u«z and v«z are linear in screen space), so a x division is 
needed. Also a tune value is stored in pixel memory for use 
in animated textures* The lighting model currently used is 
Phong shading. Sim^ aU pixels are haiwiledccmcurrently after 
all rasterization, we call this approach deferred shading.. 
Because of the high degree of parallelism achieved during 
deferred shading, we can afford to have quite elaborate 
procedural textures and lighting models while maintaining, 
high frame rates. 

Texture Programs 

Programming Model - Procedural textures are implemented 
via a simple virtual machine. This texture machine comprises 
an assembly language-like instruction set called T-codes^ a set 
of registers in pixel memory, and a set of parameters in the 
Graphics Processor memory. The pixel parameters, such as 
intrinsic color, u,v coordinates, etc, are. accessible to the 
texture machine via its pixel memory registers. The Graphics 
Processors execute the T-codes incerpretively, modifying the 
puel variables that affect shading. More exactly. - 
interpretation of a T-code program produces an IGC 
command instruction stream, which is routed to the 
appropriate Renderers for SlMD execution* 

T-Codes - There are three kinds otT-codes : generators, which 
produce several basic texture patterns, operators, which" 
perform simple arithmetic operations on texture patterns, and 
conditionals which permit selected pixels to be included or 
excluded in a computation. Generators include PerihVs band- 
hmtted noise function [Perlin 85], Gardner's sum-of-sines 
[Gardner 84], antialiased square waves, and a Julia set - 
Examples of operators include add, scale, max, square root, 
splines, and color tabic lookup. These operators can be 
cascaded to implement arbitrary functional composition. 
There are T-codes for conditional execution (by having 
selected pixel processors conditionally disable themselves), 
but no T-codes for looping. Adding a new T-code to our 
system is astrajghtforward task. Besides coding and testing of 
the T-code subroutine in C, the programmer needs only to 
update the T-code assembler parse table and the T-code 
subroutine dispatch table. 

Sample Texture Program - The following T-code fragment 
computes an antialiased black and white checkerboard 
pattern The U and V registers contain the texture coordinates, 
and the D register contains the texture scale factor. Output is 
to the diffuse color components DJted, D.Green and 
D_Blue. The swave generator produces antialiased square 
waves in one dimension. Note how the outputs of the 
generators are combined by continuous operators for 
antialiasing, rather than using bitwise exclusive -OR. 

# make antialiased square wave in U direction 

swerve R # u, D; swavejarana 
f make antialiased square wave in V direction 

swave S,v,D; swave_jiarams 
I R and S registers now contain stripes 

mul T,JC5 

add w^s 

sub w,w,3r 

sub W,W,T 
f W := R+S-2*R*s, countinuous exclusive OR 

# set diffuse colors from w 

copy D_Red,W 
copy D_Green, W 
copy O Blue,W 
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Certainly, our texture programming language is hardly state* 
of- the- art with respect to programming ease. This is 
compensated to some extent by the feet that texture programs 
tend to be rather short - typically 20*40 instructions. The 
programs are short because the built-in generators and some- 
of the operators (such as spline and color table lookup) are 
fairly powerful. The main job of the texture programmer is 
producing the appropriate "glue" code to tie these together. In 
addition, as discussed later, programming is facilitated by an 
interactive texture editor program which allows the use of' 
macros. 

Texture Procedure Evaluation Details 

Pixel Memory Management - The Pixel-Planes 5 Renderers 
contain 208 bits of on-chip memory ami 4096 bits of off-chip 
backing store memory per pixel. Backing store memory" 
cannot be directly addressed by IGC instructions, but must be 
swapped in and out by special instructions. Because texture 
programs usually require the use of scratch memory space and 
because a rather large number of pixel variables are needed to 
support deferred shading, thereis not enough pixel memory to' 
statically allocate it for the worst case. Therefore, a pixel 
memory manager keeps track of the locations of the variables 
and to perform memory movement and backing store 
swapping to make available required amounts of scratch 
memory space, - 

Caching of IGC Command* - For static texture programs, 
the IGC commands do not change from frame to frame, and 
thus the T-code translation step need occur only once. Note 
that static texture programs do not imply static textures; the 
result of executing a texture program may vary with time, if* 
time is an input variable. During texture parameter editing, 
the T-code program must be reinterpreted each time it is 
changed. The Graphics Processors cache the IGC commands 
resulting from texture interpretation to avoid generating them 
repeatedly* 

Flags - Since each Rendercr covers a small 
(125x128 pixel) region of the screen, it is likely that only a 
small subset of the textures will be represented in a given 
region. The Graphics Processors flag each region that any 
textured polygon intersects as needing that particular texture. 
The Graphics Processor thai creates the texturing commands 
for a particular region checks the QR'ed flags from all 
Graphics Processors format region, and creates and sends the 
texture programs for only those textures that might be visible. 

Obtaining Real-Time Performance 

Our goal for real-time procedural textures was to deliver at 
least 15 frames-per-secood to real applications in research 
projects at UNC This goal has been met, and these 
applications are described in a later section. 

There are two crucial issues for rapid texture evaluation. The 
first issue is to maximize utilization of the pixel processors. 
Trus is achieved by waiting to execute the texture programs 
until all polygons have been rasterired. so parallelism of the 
texture programs can be maximized. In addition, by use of 
region-hit flags, we avoid processing texture programs for 
screen regions that don't have fee texture. Hie second issue is 
enabehng the Graphics Processors to keep up with the 
Rewfcrers This is accomplished by the IGC instruction 
caclung. We increased the performance of the Walkthrough 
appnearjoo from 2 to 20 frames/see by the use of region-hit 
flags and the IGC instruction caching. 



Antialiasing Techniques 

Antialiasing of procedural textures is a difficult problem to 
which we have not found a general solution; instead we have 
developed a few techniques which work fairly well for many 
texture programs. The theoretically proper method is to 
convolve the texture with a filter kernel of an appropriate 
shape, centered at the pixel. In principle, this is possible since 
each pixel processor knows the entire texture, but in practice, 
this can be done only for the simplest textures, because 
integrating arbitrary functions of two variables is difficult. 

In orderto do antialiasing, we need some estimate at each pixel 
of how an area element in screen space maps into texture 
space. Ideally, we would use the derivatives of u and y with 
respect to screen space x and y. However because of limited 
pixel memory, we decided to record this estimate using a 
single number, called the texture scale factor. This number is 
intended to represent the maximum magnification factor that 
can occur when a unit vector in screen space is mapped to 
texture space. The texture scale factor is available in a pixel 
memory register for use in T-code programs; The 
approximation we use is max(luj+lu Uv^Wv I), which is 
within a factor of 1 .42 of the commonly used formula max 
((u^+V) 1 ". (V+y, 1 )" 2 ) for MlPmaps [Williams 83]. 
Because of this, our textures are over-blurred when viewed at 
certain angles, just like MfPmaps. Texture scale factor is 
computed for polygons as follows. When the polygon is 
rastcrized, the u and v coordinates at the middle of the 
polygon, u^ and v^are computed. The linear expression for 
uz = ax+by+c, is differentiated to give u^t+uz = a, which is 
-0 801 ^ for the constant u^z » a-u^. Similarly u v z, and 
? v^z are computed. From these max(Iurl-Mu d,fv z!+Jv if) is 
computed and stored in pixel memory. Finally, just before 
texture program evaluation, a parallel z divide is performed 
for all pixels. This is, of course, an approximation due to the 
substitution of u bU for u. The approximation error manifests 
itself as a difference in the amount of blurring at the corners 
of apolygon that is being viewed at a very oblique angle (large 
2,). We found that the error is not noticeable in ordinary 
scenes, although it can be seen in contrived test cases. 

The antialiased square wave generator produces an 
anbaliased stripe pattern with a specified phase, frequency, 
and duty cycle. The generator analytically computes the 
convolution integral of a box filler kernel with a square wave 
function of its input parameter in one dimension. The width 
of the box filter is the texture scale factor. Initially we 
implemented a triangular filter kernel, but found that it 
required too much scratch pixel memory. 

A method thai works for some textures is to antialias the final 
color table lookup. Hie idea is to return a final color (hat is the 
integral over some finite interval in the color table, rather than 
a po int sample. The width of the integration interval is 
propprdonal to the texture scale factor times the maximum 
gradient magnitude of color with respect to u and v. This 
integral is simple enough to be computed analytically in the 
pixel processors. If the gradient magnitude of the texture 
value input to the color table is reasonably smooth, this 
roughly approximates the correct convolution integral, and 
does a fairly good job in practice for many textures. It fails 
Utterly for textures that are discontinuous functions ofu and v. 
Ttus kind of texture gradually loses contrast as the texture 
scale factor increases, but before the texttircfades to a uniform 
color, there is severe aliasing. 
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Anotherrnethod works iathe frequency domain. Some of our 
texture programs "roll ofF the amplitude of the band-limited 
noise based on the texture scale factor. Hie result is that the 
noise fades to a uniform value at scales where aliasing would 
be a problem. 

Interactive Editing of Texture Procedures 

An interactive texture editor eliminates the need for an edit- 
compile-1 ink-test cycle. SineeT-code programs are executed 
interpret! vely at run time, texture procedures can be' changed 
wMiOutiecompilation. Furthermore, the interpretation phase 
is fast enough so that literal values (Graphics Processor 
parameters) in T-code instructions can be updated in a single 
frame time, at frame rates of more than 3D frames per second* 
The texture editor displays the T-code instructions of a 
selected procedural texture in a text window. The user can 
position a movable cursor on any literal value in a T-code 
instruction, and then smoothly vary this value via a joystick. 
The dynamically updated texture pattern is displayed on the 
graphics system with a two-frame lag (the graphics pipeline 
overlaps two frames). At over 30 frames per second this lag 
time is hardly noticeable. Hence the user can explore the 
(parameter space of a texture procedure continuously in real 
time. 

More drastic changes to texture programs can be made by 
interactively editing the text of the program in another 
wmdow via a conventional text editor. T-code instructions 
can be added, rearranged, and deleted, producing a new 
program. Then with a couple of commands, the user can save 
the updated texture program and reload it into the texture 
editor for immediate display. This process takes from one to 
five seconds, which due to the more discrete nature of such 
changes, can still be viewed as interactive editing. 

What the user sees on die graphics system is aeomplete scene 
with possibly many graphics primitives and texture 
procedures, not just a single isolated texture pattern. The 
texture editor provides aeomplete set of commands to access 
the facilities of our graphics library. Urns the user can change 
the viewpoint, move objects around, change the locations and 
parameters of light sources, etc This is important, because the 
appearance of a texture is dependent on its visual context. 



rt0]se(u,l) > v 



noise(ii,t) < v 




u = const 



Figure 2; Generating Flames 



Dynamic Textures 

Textures have been traditionally considered to be functions of 
spatial coordinates u and v. A generalized texture, however, 
need not be restricted to just mappings from the spatial 
coordinates. One could consider a texture to be a function of 
several other parameters as well- time and surface normal , to 
mention just a couple. Procedural textures permit us to create 
these generalized textures without the memory overheads that 
would be required with image textures. Since these textures 
change spatially based on input parameters that need not be 
restricted to just those that define the mapping, we prefer to 
call them dynamic textures. 

If we consider a textures to be a function of u, v, and t, where 
t is a time variable, we can produce time-varying animated 
procedural textures such as a fire texture that flickers and 
water waves that ripple. If we consider textures as functions 
of u , v and n where n is the normal to the surface that has been 
textured, then U is possible to do environment mapping by 
defining an appropriate procedural texture Dynamic textures 
implemented this way can still be precomputed because the 
program text for the texture doesn't change. Another way to 
produce dynamic textures is to edit the texture programs after 
each frame, but then there is some loss of performance since 
precornputation of JGC commands isn't possible/ In the 
following sections we describe how v/e implemented several 
dynamic textures. 

Fire - Anexampfe of an animated texture is a flickering flame. 
We implement a fire texture as follows (Figure 2): First 
perturb u by adding to it a 2D noise function of u and t Then 
generate a height field h by applying a 2D noise generator to 
uandt. Compute flame intensity f=l-v/h. Iff<OsetftoO 
This creates a moving outline of the flame. Because of the 
noise perturbation of u, the outline moves both vertically and 
horizontally. Finally we copy f to opacity and use acolor table 
with inputf to produce color. We use two layers of transparent 
fire texture to produce the fireplace shown in Photo 3. 

Environment Mapping - The next example is a dynamic 
texture depending on object orientation instead of time. It 
implements environment mapping of a ample checkerboard 
pattern onto a teapot. The textured teapot appears to be located 
mside a room with checkerboard walls, as shown in Photo 5. 
Kotatmg the object lets thereflections move across the surface 
in a realistic way. We accomplish this by r^rfonnjng typical 
OTvironmenL mapping computations (Blinn & Newell 76] 
(determine reflected eye vector, compute indices, compute 
procedural texture as function of indices) in aT-code promm 
for each pixel. r 5 

Our current system has two limitations for environment 
mapping. First, because the normal vector is only available in 
eye space coordinates, the (infinitely distant) reflective 
environment appears to be attached to the camera. Thus 
whenever the camera is rotated (panned, tilted or rolled), the 
reflections move across the object's surface in an erroneous 
way. If we had enough pixel memory to store woHd space 
normals this restncttoii could be removed. Second; we cannot 
perform antialiasing properly, since we do not have surface 
curvature information available in pixel memory. 

Water -The final example, shown in Photo 6. is an animated 
texture approximating water waves by means of an animated 
procedural bump map. This dynamic texture is a function of 
both ume and spatial orientation. The pixel normals are 
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perturbed on the basis of a height field whose value is 
computed at each pixel The derivatives required for the 
normal perturbation are computed by finite differences. The 
height field consists of superimposed circular and parallel 
moving sinusoidal waves generated by a number of sources 
distributed across the water-textured surface, a common 
approach far this problem. The surface characteristics are 
such that the water surface appears highly specular. In 
addition, the normals are used to compute a simple one- 
dimensicma] color scale environment map, which is used to 
create a mote natural appearance. The map has rotational 
symmetry about a vertical axis, so that the camera can be 
arbitrarily panned. However, tilting or rolling the camera 
would generate erroneous results, for the reasons mentioned 
in connection with the environment mapping texture. As 
mentioned, this restriction could be removed by storing world 
space normals at each pixel. We also have a problem with 
determining which way to perturb the surface normals, since 
we do not have the surface tangent vectors m the u and v 
directions available in pixel memory. We can circumvent this 
problem for horizontal polygons (like water surfaces) by 
broadcasting the current transformation matrix to the pixel 
processors during the texturing phase oF each end-of-frame 
calculation. The scene in Photo 6 was rendered in 33 
milliseconds, low resolution, with 24 GPs and 1 2 Rendercrs. 

Applications Using Procedural Textures 

Pixel-Planes 5. besides being a research project in its own 
right, is also an important resource for several other research 
projects at UNC Two of those for which textures are 
utrponantare the Building Wallctluoughproject and theHead- 
Mounted Display project. Both of these use a stereo head- 
mounted display and head tracking, so high frame rates are 
necessary to maintain the illusion of the virtual environment. 

Walkthrough - The UNC Walkthrough Project aims at the 
development of a sy&tcm for creating virtual building 
environments [Brooks 86J. This is intended to help architects 
and their clients explore a proposed building design prior to its 
coristniction. oOTccting problems on the computer instead of 
m concrete. Texturing plays an important role in enhancing 
image realism. Having textures forbricJcs, wood, ceiling tiles, 
etc., adds to the richness of the virtual building envtanment 
and gives an illusion of greater scene complexity. The 
radiosity illumination model is used in the Walkthrough 
? ro £5f* We can display a model of a house thai contains about 
34,000 polygons and 20 procedural textures at 15-20 frames/ 
sec on 24 Graphics Processors and 12 Renderere at 640x512 
resolution. Photo 1 shows a view of the riving room of the 
house, and Photo 2 shows a view of the kitchen. 

For enhanced realism, textures have been integrated with 
radiosity in Wdkthrough. There are two stages in this 
integrauoiL The fust stage is to calculate radiosity values for 
a textured polygon, such thatthe radiosity effects such as color 
bleeding are correctly simulated for the polygons near this 
textured polygon The second stage is to shade the textured 
polygon itself by the radiosity values at its vertices. To effect 
the first step, the color of a textured polygon is assigned to be 
the average color of its texture* This color is then used in the 
radiosity process as usual. After the radiosity values at the 
vertices of a polygon have been computed, they are passed as 
input parameters to the procedural texture for ihis polygon 
along with other input parameters such as the u and v 
coordinates. These shading values are linearly interpolated 
across the poly goa The procedural texture is computed as 
before and a post-muJriph'cation of the interpolated radiosity 



shading values with the computed texture colors at each pixel 
gives a smooth shading effect over the textured polygon. 

Another application which textures find in the Walkthrough 
project is that they offer one way. to switch lights in a virtual 
building. The total radiosity illumination of a polygon is 
determined by the dot-product of the vector of light values and 
the radiosity vector specifying the contribution of each light 
source to the illumination of the polygon. This (hen means that 
given the latter, the user can vary the intensity of alight source 
and observe the same building model under different light 
scales (but same light positions), by just computing the dot 
product as described before (Airey90). This however takes 
roughly 3-5 seconds for a data set of roughly 30.000 polygons 
and 20 light sources if done sequentially on the host 
workstation and fails to provide the effect of instantaneous 
light switching. One possibility to do this fast enough to 
provide an instantaneous effect (under a tenth of a second) is 
to do this in parallel by using T-codes. The idea is to pass the 
intensity value of a light source as an input parameter to a T- 
code program (along with the polygon colors) which 
computes the dc-t-product of the input parameter with the 
value of the interpolated radiosity (as described in the 
preceding paragraph) and uses the resulting value to shade the 
polygon. Changing the intensity of a light source can then be 
done by editing the T-code program and changing this input 
parameter. This is essentially using the T-code commands as 
a shading language, 

Head-Mounted Display - In the Head-Mounted Display 
project, the primary use of textures has so far been in a 
mountain bike simulation, where the user rides a stationary 
bicycle and views simulated terrain through the head- 
mounted display. Textures are used to increase the apparent 
scene complexity and to improve the user's perception of 
motion through the environment This application features 
relatively few textures (grass, road, and cloudy sky), each of 
which covers a fairly large area of the images. A scene from 
this application is shown in Photo 4. The cloudy sky texture 
makes use of the Gardner texture generator. The grass and 
road texture make use of band-limited 2-D noise, and are 
anualiascd by decreasing the noise amplitude as die texture 
scale factor increases. Several frequencies of noise are used 
its own uphold for rolloff. This simulation rtini 
at20-25 frames per second in low resolution (640x512) stereo 
mode using 32 Graphics Processors and 20 Rendercrs. 

Future Work 

TTte logical next step to our simple texture language is to 
implement a full-fledged shading language that can be 
executed on-the-fly. Using the deferred shading pamdigm on 
a high-end graphics machine, real-time execution of a shading 
language such as Renderraan [Hanrahan & Lawson 90] seems 
tobeaveryrealpossibiliry. Unfortunately, this is impractical 
on the current Pixel-Planes system due to the small amount of 
memory available to the pixel processors. However, it is 
likely that the Pixel-Flow machine [rvfolnar 9ih now beine 
designed at UNC Chapel Hilt, wiJl have sufficient p£el 
memory to make this idea viable. 
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